The generic JSON and CSV importers emitted only a single `cwe` per finding,
so a finding could not be imported with a CWE *set*. Mirror the existing
`vulnerability_ids` handling to accept multiple CWEs:

- JSON: accept an optional `cwes` list (popped like `vulnerability_ids`,
  since it is not a Finding field). The first entry becomes the primary
  `finding.cwe` when `cwe` is not already given; the full set is kept on
  `finding.unsaved_cwes`. Mixed int / "CWE-<n>" forms are supported.
- CSV: accept a delimited `CweIds` column alongside the existing single
  `CweId`, with the same primary-plus-set behavior; merge CWE sets across
  internally-deduplicated rows like vulnerability ids.

The import pipeline persists the set via `Finding_CWE`; normalization and
deduplication happen in `finding_cwe_labels()`. The legacy single `cwe`
path is unchanged.

Adds a fabricated multi-CWE fixture and parser tests (JSON + CSV).

Add 'cwes' to HASHCODE_ALLOWED_FIELDS and hash it via a new get_cwes(), which
mirrors get_vulnerability_ids. Because the primary cwe is a scalar that is always
set (so Finding.cwes is non-empty even before the extra Finding_CWE rows are
written during import), get_cwes prefers unsaved_cwes whenever present, so the
pre-save and post-save import hashes agree.

Tests: get_cwes prefers unsaved_cwes, is stable across save, empty with no cwe,
and cwes participates in compute_hash_code.

Mirror the existing cve/vulnerability_ids deprecation note: the single primary
cwe field is merged into the cwes set for backward compatibility and can be
removed once no longer needed.

… cached property

get_cwes() used the cwes @cached_property for the saved path; if finding.cwes was
accessed before the Finding_CWE rows were written (serializer/signal/log), it cached
an empty/partial set and the hash then used that stale value -> nondeterministic
hash_code (flaky dedup under parallel test runs). Mirror get_vulnerability_ids: read
the finding_cwe_set reverse relation directly (uncached, prefetch-honoring), falling
back to the unsaved values before save. save_cwes stores the primary cwe as a row too,
so finding_cwe_set carries the full set.

Move cwe_number, cwe_label, parse_cwes, finding_cwe_labels out of
finding/vulnerability_id.py into a dedicated finding/cwe.py (CWEs are a weakness
class, distinct from vulnerability identifiers). resolve_vulnerability_id_type
stays in vulnerability_id.py. All importers updated.

…mn width

Two data-safety fixes for the multi-CWE relation:

- FindingSerializer.update() called save_cwes() unconditionally, so any
  PATCH/PUT that omitted `cwes` deleted a finding's extra Finding_CWE rows
  (leaving only the primary). Guard the call on `parsed_cwes is not None`,
  mirroring the vulnerability-id path.

- cwe_number() had no upper bound, but Finding_CWE.cwe stores "CWE-<n>" in a
  varchar(11). A number > 9,999,999 passed validation then raised DataError
  at insert (API/form 500, and would abort the 0280 backfill's bulk_create,
  since ignore_conflicts does not swallow DataError). Reject it as invalid
  input (None) so it becomes a clean 400/skip.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Restacked onto the renumbered vulnerability-id chain; the CWE migrations move
0279/0280 -> 0283/0284 and re-parent onto 0282_unique_finding_vulnerability_id
so the branch has a single linear migration leaf again.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>